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DETAILED ACTION 



Status of Claims 

1 . This communication is responsive to the amendment filed on July 28, 2004. Applicant 
amended claims 1,2,4,5,8,10-12,14 and 17-19. Glaims 1-22 are pending. 

Claim Objections 

2. Claim 1 objected to because of the following informaHties: Change the misspelled word 
'InteropeabiHty' to 'Interoperability'. Appropriate correction is required. 



Claim Rejections - 35 USC §103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. Claims 1-22 rejected under 35 U.S.C. 103(a) as being unpatentable over 
Ramaswamy et al. (European Patent No. EP 1 058 422 Al) in view of Eytchison (US 
2001/0047431 Al). 

5. In reference to claims 1,11,19 and 20, Ramaswamy teaches a system, method and 
network respectively for facihtating UPnP control of a plurality of non-UPnP devices on one or 
more slave networks (see page 1, section (57)), the system comprising: 
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a UPnP interface to at least one UPnP controller, the UPnP controller being configured to 
issue a UPnP command in conformance with a UPnP protocol (column 2 line 33 - column 3 line 
5 and column 6 lines 25-31, Ramaswamy discloses UPnP interfacing through a UPnP controlling 
application (node D), the node issuing a UPnP commands), 

a UPnP proxy enabler that is configured to: 

receive the UPnP command (column 3 lines 1-35, Ramaswamy discloses a UPnP 
bridge configured to receive UPnP commands), 

transform the UPnP command into a device command (column 4 line 51 - 
column 5 line 51 and column 7, Ramaswamy discloses UPnP commands converted to device 
commands), 

communicate the device command to a target device of the at least one non-UPnP 
device on the slave networks (column 6. line 10 - column 7 line 40, Ramaswamy discloses 
sending a command to a non-UPnP device on a sub-network), 

wherein the one or more slave networks include one or more different networking 
technologies other than Home Audio- Video hiteroperability (HAVi) compatible network 
technology (column 14 lines 42-46, Ramaswamy discloses where different networking types 
other than HAVi can be implemented with the invention), and 

communicate a UPnP acknowledgement of the UPnP command to the at least one 
non-UPnP controller, via the UPnP interface (column 14 Hnes 9-42, Ramaswamy discloses the 
UPnP interface (node D) receiving an acknowledgement response of the UPnP command sent to 
the non-UPnP device). 
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Ramaswamy does not explicitly teach another different network. However, Eytchinson 
teaches interoperability between a HAVi network and a VHN network (Abstract and Summary). 

It would have been obvious for one of ordinary skill in the art to modify Ramaswamy by 
making the other network a VHN network as per the teachings of Eytchinson to establish 
interoperability between a UpnP network and a VHN network. 

6. In reference to claims 2 and 12, Ramaswamy teaches the system and network 
respectively of claims 1 and 11, wherein the one or more different networking technologies 
include at least one of: a USB network, a bluetooth network, , an IEEE 1394 network, a Home 
API network, a HomeRF network, a Firefly network, a power line network, an X-10 network, 
and a Jim-compatible network (page 1, section (57), column 1 Unes 30-35, column 4 lines 45-50 
and column 14 lines 42-46, Ramaswamy discloses a non-UPnP networking environment as an 
IEEE 1394 networking envirormient). , 

7. In reference to claims 3,13 and 21, Ramaswamy teaches a system, method and network 
respectively of claims 1,11 and 19, wherein: 

the UPnP controller is further configured to issue a UPnP request in conformance with 
the UPnP protocol (column 6, Ramaswamy discloses conforming to the UPnP protocol for the 
UPnP interface (node D) to send a request), 

the UPnP request includes one of: a description request, a presentation request, a 
subscription request, and a query (columns 12-14, Ramaswamy discloses UPnP requests 
including requests and query/detection), ajid 

the UpnP proxy enabler is configured to provide at least one of: a device description a 
service description, a presentation page, an event, and a value of a variable, in response to the 
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UpnP request (columns 3-5 and column 6 lines 1-40, Ramaswamy discloses UPnP bridge (node 
C) configured to provide responses to the UPnP requests). 

8. In reference to claims 4 and 14, Ramaswamy teaches a system and method of claims 1 
and 11, wherein: 

the UPnP proxy enabler includes at least one of a discovery module that is configured to 
provide an advertisement of at least one of the non-UpnP devices to the UPnP controller (column 
3 line 1 - column 4 line 15 and column 13 lines 19-55, Ramaswamy discloses the bridge 
providing an ANNOUNCE message indicating discovery of a non-UPnP device to the UPnP 
network), 

a description module that is configured to provide a description of functions of the 
plurality of non-UPnP device to the UPnP controller, in response to a request from the UPnP 
controller (column 3 line 1 - column 4 line 15 and column 13 line 55 - column 14 line 25, 
Ramaswamy discloses providing a description of the non-UPnP device to the UPnP network), 
and 

a presentation module that is configured to provide a presentation page that facilitates a 
control of the plurality of non-UPnP device by a user (column 3 line 1 - column 4 Une 15 and 
columns 6 & 14, Ramaswamy discloses a control presentation to control the non-UPnP device by 
a user). 

9. In reference to claims 5 and 15, Ramaswamy teaches a system and method respectively 
of claims 4 and 14, wherein at least one of the discovery module, the description module, and the 
presentation module is configured to provide the advertisement, the description, and the 
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presentation page, respectively, for the at least one non-UPnP device of the slave networks 
(columns 3,4,6,13 & 14, see above). 

10. In reference to claims 6 and 16, Ramaswamy teaches a system and method of claims 1 
and 11, wherein the UPnP proxy enabler includes at least one of: 

a device control module that communicates commands to the target device (column 6 line 
10 - colunm 7 line 40, Ramaswamy discloses sending a command to a target non-UPnP device 
on a sub-network), 

an event subscription module that receives requests from the at least one UPnP controller 
to be notified of one or more changes of state of the target device (column 5 line 45 - column 6 
line 58 and column 13, Ramaswamy discloses bridge receiving request from UPnP interface 
device (node D) for non-UPnP device (target device) information (state)), and 

an event source module that notifies the at least one UPnP controller of one or more 
changes of state of the target device (column 3, column 5 line 45 - colunm 6 line 58, columns 13 
& 14, Ramaswamy discloses bridge notifying UPnP device (node C) which notifies UPnP device 
(node D) of state changes in the non-UPnP target device). 

11. hi reference to claims 7 and 17, Ramaswamy teaches a system and method of claims 6 
and 16, wherein: 

the device control module maintains a service state table that reflects the state of the 
target device (column 3 & 13, Ramaswamy discloses maintaining a representation of each 
network element by the bridging device), and 

the event source module notifies the at least one UPnP controller of the one or more 
changes of the state of the target device based on the service state table (column 3, column 5 line 
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45 - column 6 line 58, columns 13 & 14, Ramaswamy discloses bridge notifying UPnP device 
(node C) which notifies UPnP device (node D) of state changes in the non-UPnP target device). 

12. In reference to claim 8, Ramaswamy teaches a system of claim 1, wherein the UPnP 
proxy enabler communicates the device command to the target device by modifying a data 
structure that is associated with a thread, and the thread effects the communication to the 
plurality of non-UPnP device of the slave networks (column 5 line 45 - column 7 line 58 and 
column 13, Ramaswamy discloses the bridge communicating device command to non-UPnP 
device). 

13. In reference to claim 9, Ramaswamy teaches system of claim 1 , wherein the UPnP proxy 
enabler is further configured to detect a connection and disconnection of the at least one 
non-UPnP device, and update one or more data structures associated with the slave networks 
accordingly (column 5 line 45 - column 7 line 58 and column 13 line 1 - column 14 line 25, 
Ramaswamy discloses bridge detecting addition/removal of non-UPnP device and updating 
configuration data). 

14. In reference to claim 10, Ramaswamy teaches system of claim 9, wherein the UPnP 
proxy enabler is further configured to initiate and terminate threads based on the connection and 
disconnection of each of the plurality of non-UPnP device (column 5 line 45 - column 6 line 58 
and column 13 line 1 - column 13 line 25, Ramaswamy discloses initiating and terminating 
messages based on the addition/removal of non-UPnP devices). 

15. In reference to claims 1 8 and 22, Ramaswamy teaches the method and network 
respectively of claims 1 1 and 19, further including creating a thread that is associated with each 
of the plurality of non-UpnP devices of the slave network, and modifying a data structure that is 
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associated with the thread; and wherein the thread is configured to effect the communication of 
the device command to each of the pluraHty of non-UpnP devices of the slave network, based on 
the modification of the data structure (column 5 fine 45 - column 7 line 58 and column 13 line 1 
-column 14 line 25). 



Response to Amendment 

16. Examiner acknowledges the amendment filed on July 28,2004. Applicant amended 
claims 1,2,4,5,8,10-12,14 and 17-19. 

Response to Arguments 

17. Applicant's arguments with respect to claims 1-22 have been considered but are moot in 
view of the new ground(s) of rejection. 

18. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE HNAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS fi-om the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
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the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 . 1 36(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry conceming this communication or earlier communications from the 
examiner should be directed to Ramy M Osman whose telephone number is (703) 305-8050. 
The examiner can normally be reached on M-F 9-5. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, Ario Etienne can be reached on (703) 308-7562. The fax phone number for the 
organization where this appUcation or proceeding is assigned is 703-872-9306. 

Information regarding the status. of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



RMO 

October 20, 2004 
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(54) Metliods for bridging a HAVi sub-network and a UPnP sub-network and device for 
implementing said methods 



(57) The invention concerns methods for bridging a 
HAVi sub-network and a UPnP sub-network. 

For making UPnP devices available to the HAVi 
sub-netvM}rk, the following steps are implem^ted:, 

- discovering UPnP devices and/br servfces on the 
UPnP sub-network and corresponding to a selec- 
tion criterkm; 

- declaration, by a sub-network bridging device, of 
each discovered UPnP device as a HAVi DCM and 
of each discovered UPnP sen^ice as a HAVi FCM 
on the HAVi sub-network. 



For making HAVi devices available to the UPnP 
sub-network, the following steps are implemented: 

- dfecovering HAVi software elements of the HAVi 
sub-network corresponding to a selection critenon; 

- representing, in a sub-network bridging devtee, 
each of saki discovered elements by a UPnP proxy 
service identified by a port number attributed by 
said sub-network brkiging device; and 

- announcing each said proxy sendees on the UPnP 
sub-network. 

The invention also concerns a device (or imple- 
menting the above steps. 
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Description 

[0001] The inventbn concerns methods to bridge 
HAVi and UPnP sub-networks, a first method address- 
ing the issue of making UPnP objects available to HAVi 
objects, a second method addressing the issue d mak- 
ing HAVi objects available to UPnP objects. Tt\e inven- 
tion also concerns a bridge device. 
[0002] The invention applies among others to home 
networks. 

[O0O3] Several sub-networks based on different phys- 
ical media (wired and wireless) and applicatksns are ex- 
pected to coexet in a digital home network. Common 
examples of wired physical media include the coaxial 
cable, twisted pair wiring, power line artd optical fibers. 
A digital home network also needs to contend with the 
technological developments within the computer, con- 
sumer electronics, telephony and home automaton in- 
dustries. 

[0004] There have been two recent initiatives within 
the industry to address different needs: 

1. Home Audio-vkJeo inleractivily (HAVi) 

2. Universal Plug and Play (UPnP) 

[0005] There is a need tor harmonizatk)n of the two 
system approaches in order to ensure coexistence and 
interoperability of devices within these domains. One of 
the goals of the invention is to accomplish the bridging 
of the two technological approaches. 
[0006] The first initiative, Home Audio-Video Interop- 
erability (HAVi), started within the consumer industry is 
an attempt to accomplish high speed interconnectivity 
over an IEEE 1394 serial bus network for transacting 
audic^ual data. This initiative was specifically Intend- 
ed to address the needs of the consumer electronics de- 
vices to enable interactivity (with user involvement in a 
user-device interactkin paradigm) and interoperability 
(with no user involvement in a device-device interactkxi 
paradigm). Further, within HAVi, there is a strong em- 
phasis on enabling streaming applications in addition to 
control applications. An example of a streaming appli- 
cation wouk5 be an application transferring a video 
stream from a recording device to a decoder or display, 
while an example of a control application wouk) be an 
appRcation for programming the behavbr of devices. 
This implies a support for both isochronous and asyrv 
chronous transactions. 

[0007] The other key features of HAVi include: 

1. Hol Plug and Play 

2. Hardware and Operating System Platform neu- 
trality 

3. Support for legacy devices (i.e. devices with no 
HAVi functionality) and a gradual evolution to sup- 
port new technotogies 

[0008] The second initiative is Universal Plug and 



Play (UPnP). While HAVi is intended prinrarily for a high 
sp^ I EEE 1 394 network for AudioNideo transactbns, 
UPnP is an initiative that is physical layer agnostic and 
expects to work on a TCP/IP network. The general no- 

s tions and paradigms are based on the Internet protocols 
with additions to support the notions of plug and play. 
[0009] The foltowing non-exhaustive list of docu- 
nr^nts describe the above architectures in their current 
state of development, at the priority date of the present 

10 application: 

For HAVi: 

The HAVi 1 .0 beta+ specifk:ation. dated October 23, 
1998 

IS 

[0010] The UPnP technotogy comprises a set of pro- 
tocols based on TCP/IP 

- 'Automatically choosing an IP Address in an Ad-Hoc 
20 IPv4 Network* (<draft-ietf-dhc-ipv4-autoconfig- 

04.txt>) 

- •Simple Sendee Discovery Protocol 1.0* ( <http :// 
search, ie. oro^ntemet-drafts/draft-cai-ssd p- 
v1-01.txt >) 

2S - "Multicast Discoveryof DNS (Domain Name Server) 
Sen/ices* (<draft-manning-multicast-dns-01.0ct>). 

- •Extended Martcup Language* - XML (1 .0 W3C rec- 
ommendatkxi) 

30 [0011] More information concerning these two archi- 
tectures is available on the con-esponding websites, ie. 
www.HAVi.org and www.UPnP.org. 
[001 2] The fundamental goal of the interoperability is 
to ensure that a uniform control paradigm, i.e. model, is 

3S presented so that devices in both the HAVi sub-networt( 
and the UPnP sub-network are able to interact with de- 
vices and perform control f unctkxis over their respective 
sut>-network boundary. 

[0013] Since HAVi and UPnP based devices are ex- 

40 pected to proliferate within the home, it would be nec- 
essary to ensure the interoperability of devices within 
these domains. Figure 1 represents an example of a 
home network composed of a HAVi based home sub- 
network and a UPnP based home sub-network that are 

45 brkiged together. Nodes A and D are displays where the 
user can view the networic topology and can control, 
through an appropriate user interface^ any node on ei- 
ther network. This Implies that from node A. the user 
should for example be able to detect the connection of 

so riode E to the UPnP networic and should be able to con- 
trol it. In a similar manner, a user of node D on the UPnP 
sub-networic shouk) be able to detect the appearance of 
a new HAVi device within the HAVi sutMietwork and 
should be able to control it 

55 [D01 4] In Figure 1 , the two sub-networks are built over 
two different media. However, the problem to be solved 
is the same in the situatbn where both network archi- 
tectures are built over the same rr^ia as shown in Fig- 
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ure 2. The nodes A. B and C are HAVi aware and the 
nodes C. D and E ar UPnP aware. In both configura- 
tions, there is a node (node C in both examples) which 
implements the bridg function in order to nable the 
control of any across the entire network. 
[001 S] The invention aims at provkiing an interfacing 
solution in both of the above cases, 
[0016] The object of the invention is a method for 
bridging a HAVi sub-network and a UPnP subnetwork 
comprising the steps of: 

. discovering UPnP devices and/or services on the 
UPnP sub-network and corresponding to a selec- 
tton criterion; 

- declaration, by a sub-network bridging devk:e, of 
each discovered UPnP device as a HAVi DCM and 
of each discovered UPnP senrice as a HAVi FCM 
on the HAVi sub-network. 

[001 7] According to a preferred embodiment, the dis- 
coveiy step is carried out using Simple Sen^ice Discov- 
ery Protocol (SSDP) functkxis. 
[001 8] Another object of the invention is a method for 
bridging a HAVi sub-network and a UPnP sub-network 
comprising the steps of: 

- discovering HAVi software elements of the HAVi 
sub-network corresponding to a selection criterion; 

- representing, in a sub-network bridging device, 
each of said discovered elements by a UPnP proxy 
service kJentified by a port number attributed by 
said sub-network bridging device; and 

- announcing each sak) proxy senrices on the UPnP 
sub-network. 

[001 9] According to a preferred embodiment, the dis- 
covery step comprises the step of requesting, by said 
sub-network brkiging device, a list of software elements 
from a HAVi registry. 

[0020] According to a preferred embodiment of the in- 
ventions above, the selection criterion is HTTP/HTML 
capability. 

[0021] Another object of the inventksn is a device for 
bridging a UPnP sub-network and a HAVi sutwietworic 
bnplementing the above method steps. 
[0022] Other characteristics and advantages of the in- 
vention will become apparent through the descriptbn of 
a non-limiting, preferred embodiment, described with 
the help of the attached drawings among which: 

- figure 1 . already described, represents a HAVi net- 
wori( and a UPnP network linked through a bridge 
device; 

- figure 2, already described, represents a single net- 
work comprising both HAVi and UPnP compliant de- 
vices; 

- figure 3 represents the networks of figure 1 in which 
each network comprises an HTML browser capable 



device; 

figure 4 is a schematic diagram of protocol stacks 
in the bridge device. 

5 [0023] In additnn to th documents cited in the intro- 
ductkxi of the present application, one should also refer 
to the Hypertext Transfer Protocol ('HTTP) 1.1 for fur- 
ther background information. 
[0024] Within the context of the UPnP networic. tt is 

10 necessary to detect the entry of a new device into the 
network, announce its capabilities in a well defined nnan- 
ner and allow the conunencement of interactbn with 
other devices within the networie The SSDP protocol 
and XML operating over the TCP/IP network are used 

'5 to accomplish this f unctkxiaiay. 

[0025] For user control. HTML may be used instead 
of XML 

[0026] As described earlier. HAVi is a complete sys- 
tem solution to the interoperabifity of devices with a 
20 IEEE 1394 interface. HAVi addresses, among others, 
the following issues: 

1 . Registration of devices/functions 

2. Communk^ation media management (the media 
ss being an IEEE 1 394 serial bus in this case) 

3. Modeling devrces and functkxis within devices 
using devk:e control modules ('DCMs*) and function 
control modules ('FCMs*): 

30 - the list of senrices provided by the DCM in- 

cludes connection management, status que- 
ries for the device and its plugs 
- there is a comprehensive list of FCMs repre- 
senting the rnoeX common consumer electronic 

35 functnnal elements 

4. Event management (using an event manager) 

5. Stream management (using a stream manager) 

6. Resource management 

40 7. Support for legacy devtees 

B. Data Driven lnteractk>n (DDI) mechanism 

[0027] Some d the services offered within the HAVi 
paradigm are simitar to those envisioned within the UP- 

45 nP paradigm. The important additbns to HAVi include 
specifk: provisions for stream management, communi- 
cation media management and resource management. 
These additbns are quite important in the context of an 
AA/ network based on the IEEE 1 394 bus. which impos- 

50 es severe real time constraints. 

[0028] One of the issues regarding the interaction be- 
tween the HAVi and UPnP sub-networks is the need for 
a common user control protocol. The DDI mechanism, 
whk:h ts standard in HAVI , is not standard within the UP- 

55 nP networic HTML is standard in an I P based computer 
network (including UPnP). but is not included in HAVI.' 
In order to solve this problem, the following functbnali- 
ties are required: 
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a user control protocol which can be used across 
the whole network : HTML 
- A bridge function which will allow : 

(a) connection of the two different discovery 
protocols 

(b) carrying the HTML data over the entire net- 
work 

[0029] The Hypertext Transfer Protocol (or HTTP) is 
a request/response protocol. This protocol is introduced 
in the current context since it is the proposed mecha- 
nism to accomplish the brkiging functkxi alluded to in 
the preceding sections. 

[0030] The request/response mechanism dictates a 
client/server model for devices using HTTP, Two objects 
are involved in HTTP : the client, which sends a com- 
mand, and an origin server that receives the command 
and sends back the response. 
[0031] The HTTP protocol has a list of well defined 
methods (or commands) which include the folbwing: 

1. Option 

2. Get 

3. Head 

4. Post 

5. Put 

6. Delete 

7. Trace 

[0032] The most commonly used command is GET < 
URL> where the Uniform Resource Locator (URL) 
points towards the object to be obtained. This reference 
is composed of two parts : the first points towards the 
server equipment and the second points towards the ob- 
ject associated with the command. This target object 
can be an existing object such as a HTML script or a bit- 
map or other objects. However the object reference can 
point towards something that has a meaning for the 
WEB sen/er but does not represent any real object. TTiis 
is used, for instance, in an HTML script to signal to the 
WEB server that the user just selected an icon. After the 
user selects the icon, the HTML script associates this 
icon with a URL v/htch win be sent to the WEB server 
(through the GET command).A URL reference can in- 
clude some parameters as a comn^and from upper layer 
protocols. 

[0033] Basically, a user (application) needs is to be 
able to detect the network changes (new or renuived 
device/sennces) and then has to be able to control de- 
,vices through a User interface (a well known language 
or protocol). 

[0034] We first address the user control interface 
model of both networics. TTien, we apply the recom* 
mended solution to brklge other control protocols to op- 
erate UPnP and HAVi services over the entire network. 
[0035] Each network technology specifies a way t 
dynamically discover the appearance r the disappear- 



ance of sendees and devices. The first task of the brdge 
functton is t connect both discovery methods. For that 
we need: 

5 - a way to represent and to reach a UPnP device/ 
service for a HAVI application within the bridge de- 
vice; 

- a way to represent and to reach a HAVi device/sen^- 
ice for a UPnP applicatbn within the brkfge device. 

10 

p)036] The UPnP protocol for this functton is the Sim- 
ple Discovery Protocol (called SSDP) alluded to in an 
eariier section. The HAVi protocol for the corresponding 
functk)n is the Registry. 
IS [0037] Re^rding the bridging of the User control in- 
terface we need to map the HAVi and the UPnP worlds. 
HAVi specifies two protocols which are different from 
HTML To solve the problem we need: 

^ - a user control protocol which can be used across 
the whole network : HTML/HTTP; 

- a way to implement the HTTP protocol vnthin the 
HAVi paradigm. 

25 [0036] Regarding the bridge of other services (UPnP 
or HAVi] we need: 

- a way. for a HAVi applications to operate the UPn P 
sen^ice/device; 

^ - a way. for a UPnP applicatkxi to operate the HAVi 
sen/ice/devtce. 



[0039] In Figure 3, the bridge function is included in 
the device C. Any devk^e, irrespective of its functionality. 
35 couki contain the bridge functbn. What is needed is that 
the host device gathers the HAVi mkldleware and the 
UPnP protocol stack. For clarity purposes, the C device 
according to the present embodiment does not provkle 
any functionality other than the brkige as described be- 

40 k)W. 

[0040] The next sectkxi descrOses all operations nec- 
essary to realize the folk>wlng scenaros: 

- Scenario 1: the network topotogy is the same as 
45 shown in the Figure 3 except that the E device is 
not present The User application of A (the HTML 
browser) after power on, is able to give back to the 
userthe networi^ list c/t the HTML controlled devices 
(discovery through the HAVi registry). The E device 
50 Is plugged on to the UPnP networie The User ap- 
plication detects this new device (through the AN- 
NOUNCE method of SSDP). Then the user wrill be 
able to control the E devk^ using HTML. 

ss - Scenarb 2: the network topotogy is the same as 
shown in the 3 except that the B device is not 
present The User applk:ation of D (the HTML 
browser) after power on, is able to give back to the 
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user the network Dst cA the HTA^L controlled devices 
(discovery by SSDP queries). The B device is 
plugged on to the HAVi network. The User appltca- 
Ikxi detects this new device (announcement). Then 
the user will be able to control the B device using 
HTML 

[0041] HTML data is transported using the HTTP pro- 
tocol. However. HTTP is a means to transport any type 
of hyper text based content Just as through HTTP we 
are able to obtain any User Interface object, such as an 
icon or a bitmap, we are able to transport XML content 
as wen. Today, the most popular Markup language is 
HTML Consequently many product tools already exist. 
This is the reason we recommend using rt within the 
HAVi network. XML is an emerging standard, and could 
be used instead of HTML without any modifk^tion to our 
proposal since XML content can be transported over 
HTTP as well. According to a variant embodiment. XML 
and HTML are used tointly. 

[0042] This section proposes to add HTTP (HTML) 
capabDttles to the HAVi specification. This protocol Is a 
simple command/response protocol between a control* 
ler and a target (called HTTP server as weD). In HAVi. 
each device is represented by a software component 
called a DCM (Device Control Module). This DCM con- 
tains a certain number of wed specified entry points (as 
a set of functions) which can be used (called) by any 
other software element of the HAVi network. Like a C 
function, when a software element calls a function of a 
DCM (whether remotely or kx»lly, it is transparent for 
the caller), an associated process is started and the 
function returns the result of the process. To implement 
the HTTP paradigm, this inventk« proposes to add a 
fiew functksn set Q within the DCM API to offer the pos- 
sibility to handle the HTTP protocol between two HAVi 
software elenrtents - for example between an applk;ation 
(a browser) and a DCM (the HTTP server)-. HAVi uses 
the IDL (Interface Definitkxi Language) to specify a 
tuncton. Due the nature of the HTTP protocol, it is pos- 
sible that HTTP requests or responses contain a very 
largo payload. The transport layer of HAVI specifies a 
limit on the message size that can be exchanged be- 
tween two HAVi software elements. However HAVi 
specifies a way to handle such large messages by a rec- 
ommended design of the API of the element potentially 
involved in such communicatk)n5 (see APIs for Bulk 
transfer). 

[0043] The following code illustrates the proposed 
API extenskxi for the DCM which would implement an 
HTTP sender. 

enum FileLoc (START, MIDDLE, END}; 
[0044] Permits to indicate whether the message from 
a producer to a consumer is the first one. a mkkJIe one 
the last one. If the stream to be sent fits into one mas* 
sage, the END value will be used. 
Status DCM::HtlpOpen( 

in short dientBufferSize, 



in OperationCode opCoda, 
out long cid. 

out short Sen/erBufferSize) 
dientBufferSize : indicates the maximum siz (m 
s bytes) of a message accepted by the requester. Th 
DCM will take into account of that parameter during the 
sending of the HTTP response to the dient. 

opcode : this is the operation coda the DCM will 
use to give back to the client the HTTP response. The 
10 dient flundion identified by this operation code must be 
designed according to the protege named <dient>:: 
HttpResponse. 

cki : the identifier of this HTTP connectnn with the 
DCM. It alksws several connecttons from the same soft- 
15 ware element client and also permits to match a re- 
sponse with a request. 

SefverBuff erSize : indicates the maximum size (in 
bytes) 6t a message accepted by the DCM. The HTTP 
client win take into account of that parameter during the 
20 sending d the HTTP requests. 

[0045] This fundton allows a software element client 
(or HTTP client) to open a HTTP connection with a DCM. 
\P0A6\ The error codes for this function are the follow- 
ings: 

2S DCM::ENUM_CONN: maximum number of 
opened oonnedbns is reached for this DCM 
DCM::EALLOC: resource allocation error 
Status DCM::HttpCk>&e(tn long cid] 
[0047] The parameter ctd is the identifier of this HTTP 
so connection with the DCM. This function is used to ck)se 
a connection with a Web proxy FCM. The error code is 
the following: 

DCM::ECID: The cid is unknown. 
Status DCM::HttpRequest( 
35 in long cid. 

BTi FileLoc where, 
in saquence<octet> data) 
Parameters 

ckj: the klentifier of the connection between the 
40 HTTP client and the DCM (acting as a HTTP sender) ob- 
tains by the HTTP dient from a DCM::HttpOpen call. 

where: informs the DCM that this message is the 
first, the last or a middle one of the request . 

data contains a part or the entire request accord- 
4S ing to the HTTP protocol 
Description 

This fundion allows a software element client (or 
HTTP client) to send a request to a DCM acting as a 
HTTP sever according to HTTP. 
50 En^or codes 

DCMESIZE: the data exceeds the size of the buff- 
er in the receiver. The receiver has not received or proc- 
essed the data It is left to the implementation how the 
sender reads to this status error. 
55 DCM::EFAILED: the receiver has aborted the 
transfer of the current sequence of data transfers. The 
sender shall abort the transfer of the current sequence. 
DCM::ECID: The cid Is unkrwwn. 
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Status <Ctient>::HttpResponse( 
in long cid, 
in FileLoc where, 
tn &equence<octet> data) 
cid: the identrfier of the connection between the s 
HTTP client and the DCM. 

where: informs the client that this message is the 
first, the last or a middle one of the response . 

webData: contains a part or the entire response 
according to the HTTP protocol used through the con- io 
nectton identified by the cid parameter. 
[0048] This is the prototype of the function to be im- 
plemented in the client which allows the DCM (acting as 
a HTTP sewer) to give back to the client a HTTP re- 
sponse corresponding to a previously received HTTP is 
request from that client through that connection identi- 
fied by 'cid'. 

[0049] The error codes are the followings: 

WebProxy::ESIZE: the data exceeds the size of 

the buffer in the receiver. The receiver has not received 20 

or processed the data. It is left to the implementation 

how the sender reacts to this status. 

WebProxy;:EFAILED: the receiver has aborted 

the transfer of the curent sequence of data transfers. 

The sender shall abort the transfer of the current se- 2S 

quenco. 

WebProxy::ECID: The ckJ is unknown. 
[0050] In HAVi, thedesignerotatargetdevk:ecande- 
cide which user control protocol (HAVi currently speci- 
fies two protocols) to implement It is not even necessary so 
to provde some user control capabilities as specified in 
HAVI For the controller appficalkxi, it is necessary to 
know whether a particular target is user-control capable 
or not This is the goal of an attribute in the HAVi registry. 
The Registry is a database where all software elements 3S 
are registered (Including DOM and applcatbn module). 
Any software element can query the datat>ase. Each 
time an element is added or removed, a con-esponding 
network event is generated. An element is registered 
with a set of attributes to characterize it. One of these 40 
attnbute is the GUIREQ attribute. The possible values 
are: 

• NO.NEED 

• DDI (the basic Ul protocol in HAVi) ^ 

• HAVLET (the Java based Ul protocol in HAVi) 

[0051] The invention proposes to add a new value for 
this attribute as the following: 

so 

• HTTP (the HTTP/HTML paradigm in HAVi) 

[0052] When a user wants to control a device, its as- 
sociated client applicatbn, typically an HTML browser, 
exposes the set of network devices HTTP/HTML capa- ^ 
ble (by querying the Registry on the corresponding 
GUIREQ attn*bute value). The user selects one of these 
and the client application can send the HTTP GET conrt- 



mandtowardstheDCMofth selected target, according 
to that protocol. To send the HTTP command, the client 
applcatbn first establishes an HTTP connection iwith 
the target DCM (catting the DCM::HttpOpen method) 
and then performs one r several calls (depending on 
the size of the request and the capabililias of the target 
OCfA in term of the HAVi message size) to the DCM. 
The DCM then uses DCM: HttpRequest to send its HT- 
TP request Once the target receives the command, it 
sends back the Home HTML page associated with the 
device to the client by calling one or wore times the client 
method called 'HttpResponse'. The client application 
(the browser) then interprets the HTML script and dis- 
plays the User Interface. 

[0053] The bridge f uncton is implemented m a device 
(called the bridge device or simply the bridge) which is 
connected to both subnetworks as shown in Figure 3 
(device C). Thus it has to contain, at least the protocol 
stack as shown in the Figure 4 .Since the SSDP protocol 
requires some multicast capabilities, the IP layer will be 
IGMP ('Internet Group Management ProtocoT) compli- 
ant 

[0054] The modelization of a UPnP device or senrice 
seen from the HAVi sub-network will now be described. 
[0055] The UPnP networtc is composed of devices 
that offer access to some network senm^es. The SSDP 
protocol should permit the discovery of the sen/ices 
available in the network and indirectly the device that 
hosts the sennce. The HAVi network is composed of de- 
vk:es that contain one or more functional components 
(equivalent to sen^ices in UPnP). To represent a devk:e, 
we have to use the DCM representation. To represent 
a f unctkanal component we have to use the FCM repre- 
sentation. In HAVi. the User interface protocol is man- 
aged through the DCM API. 
[0056] Consequently: 

- A UPnP device will be represented by a DCM in the 
bridge device. 

- This DCM will contain the HTTP extra API. 

- A UPnP sen^ice (except for the HTTP sen^ice) will 
be represented by a FCM in the bridge device. 

[0057] It is mandatory to register these DCMs and FC- 
Ms through the HAVi REGISTRY service to altow any 
other HAVi object to discover them and, thus, to be able 
to operate them. The registration consists in regtetering 
the HAVi addresses of these software elements and the 
mandatory attributes according to the HAVi specifica- 
tion: 

- Type of software element (either DCM or GENERIC 
FCM) 

- HUID (unique hardware identifier: computed by the 
bridge device) 

- Device class (LAV - meaning Legacy device) 

- GUIReq (HTTP) 

- DeviceManufacturer (manufacturer f the UPnP de- 
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vice/service) 

SoftwareElemenlVerston (computed by the bridge 
device) 

UserPreferredName (computed by the bridge de- 
vice - based on the UPnP service/device name) 



- The Device manufacturer name 
• The Device name 

- The URL to get an icon r presenting the device 



5 [0085] For the PCM: 



[0058] Before the bridge device is able to activate and 
register a DCM/FCM con^espondmg to a UPnP device/ 
service, it has to detect its presence within the UPnP 
sub-network. 

[0059] According to the SSDP (Simple Service Dis- 
covery Protocol) of UPnP. the bridge device acts as a 
SSDP client and sender. Once the bridge device is con> 
nected to the home network, its SSDP client has to que- 
ry the UPnP sub-network by sending the multicast OP- 
TIONS message over UDP/IP to query the SSDP send- 
ers. The SSDP OPTIONS message will have the follow- 
ing format according to the HTTP specification: 

OPTIONS _•_ HTTP/1 .1 Request-ID: uuid: 
1313Alt-Locations: <httpuy/bridge,oom/bar.1111> 
[0060] This message contains the type of sen/ices 
concerned by the query (_•_ meaning : all), the version 
number of HTTP, a unique kientifier to nnatch the re- 
sponse with the query (the value shall respect a format 
described in the RFC 251 8). and the URL the responder 
will use to give back its response(s) (the port number 
1111 correspond to the SSDP client of the bridge). 
[0061] Alt UPnP devices will send back one or several 
SDDP OPTIONS responses (one by service implement- 
ed within the device) containing the name of the service, 
the network location of the sennce (the URL used to 
reach the sendee), the protocol to be used to communi- 
cate with the service and a set of data to describe the 
device which hosts the servk» according to the follow- 
ing: 

Device rr^ufacturer name 

- Device name 

- A URL to obtain an icon representing the device 
[0062] The bndge device parses all responses and: 

- For each new device detected, it installs and de- 
clares a HAVi DCM and registers it with its well 
specified attributes as described eariier. 

For each new sen^e type, for whk:h the bridge 
wants to offer the access to the HAVi network, it in- 
stalls and declares a HAVi FCM and registers it with 
its well specified attributes as descn'bed eariier. 

[0063] Consequently the DCM, respectively the FCM 
shall nnaintain a set of configuration data to be able to 
identify and join its associated UPnP device, respective- 
ly service. 

[0064] For the DCM: 

- The URLtojoin the HTTP serverof the UPnPdevice 
(if this service is implemented in the devk^e) 



• The URL to join the UPnP servk:e 
- The type of the UPnP service (printer for example) 
The Device manufacturer name of the UPnP host 
10 device 

The service name of the UPnP sen^ice 

(PrinterRoom2 for example) 

The URL to get an icon representing the device 

15 [0066] When a UPnP devce is plugged into the net- 
woric it has to send the SSDP ANNOUNCE message 
containing the name of the network service it provides , 
the networic bcatktn and protocol to be used to oommu- 
nk:ate with it The SSDP sender of the bridge is listening 

20 to the well known multicast port number. Thus for each 
incoming ANNOUNCE message, the bridge device wfll 
parse the message according to the manner described 
betow. 

[0087] For each detected UPnP devico/sen^ice, the 
brkJge devce installs a DCM^CM to control this UPnP 
devk^e/service as explained in the previous sections. 
The HAVi sub-networic has the knowledge of these new 
elements. Any appPtcation in the HAVi sub-network can 
then control a UPnP target. In our example (cf Figure 3) 

^ the A device provides the user with the list of devices in 
its home networic represented by icons. To realize that, 
the user application of A (an HTML browser) has previ- 
ously queried the HAVi registry to get all the identiriers 
of DCMs which were able to offer an HTTP API. 

3S [0088] The user wouki like to control the Edevtoe us- 
ing HTML and selects its associated kx)n. The user ap- 
plicatkxi in A establishes the HTTP connection with the 
associated DCM. The User applk:artbn then sends the 
HTTP request to the DCM calling the functkxi DCM::Ht- 

40 tpRequest. The DCM then establishes the TCP connec- 
tion according to HTTP between the brkJge devce (C) 
and the UPnP target (E) and forwards the HTTP re- 
quest. To establish the connection, the DCM will use the 
URL associated with the HTTP sender senrice of the UP- 

4S nP target prevbusly registered as conftguratk)n data. 
[0089] Once the HTTP command (the HTTP_GET 
command for instance) is received by the UPnP target, 
it sends back the response (an HTML page) to the DCM 
which will forward this response to the source of the re- 

50 quest. 

[0070] The modelizatbn of a HAVi target seen from 
the UPnP sub-networti will now be described. 
[0071] The UPnP model is based on the TCPAJDP/IP 
protocols. Consequently, a UPnP devfce is a network 
ss entity whbh can be reached through its IP (Internet Pro- 
tocol] address. A servce is an entity within the applica- 
tion layer (over TCP or UDP) which can be reached 
through a port number. The port number identifies the 
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connection path between two UPnP entities (an appli- 
cation and a sen^ice for example). T represent a HAVi 
device r a HAVi functional component within the bridge 
we basically have two solutions: 

The first solution is based on port numt>ers and is 
used for the rest of the description, as explained be- 
low. 

- The second solution is based on multiple IP ad- 
dresses: local IP addresses are assigned to each 
device or functional component within the HAVi net- 
work. This assignment can be made to be cons'st- 
ent with the SSDP mechanism The invoked HAVi 
component (either a OCM or an FCM) can, on in- 
stantiaticn, request a unique IP address assign- 
ment just as any other UPnP device entering the 
UPnP network, 

[0072] The rtolton of a "device* in UPnP is used only 
to reach the network entity and to obtain data describing 
the location where the service reskles. Consequently 
there is no need to represent a HAVi device as a UPnP 
device. What is needed it to represent some HAVi serv- 
ices as the HAVi functk>rial component APIs (FCM) and 
the HTTP API (offered by the DCM). According to the 
present embodiment, the socalled port number solutnn 
consists in representing a HAVi seivtee by a proxy UPnP 
sennce (like a HTTP proxy server) where each proxy is 
associated with a port number (either TCP or UDP) at- 
tributed by the bridge. 

[0073] UPnP requires that for any new een^ices the 
SSDP client of the hosted device announce the service 
list it owns. The brkJge uses the HAVi REGISTFIY to be 
able to query or detect the new HAVi targets as FCM or 
DCM according to the appropriate criteria, which is, ac- 
cording to the present embodiment, the GUIREQ value. 
[0074] Consequently, once the bridge detects a H AVt 
target (either a DCM or a FCM) for which a proxy UPnP 
sen^ice can be activated, it generates the SSDP multi- 
cast ANNOUNCE message to the UPnP subnetwork 
The folk>wing ANNOUNCE message is used to an- 
nounce a HTTP server service represented by a HTTP 
proxy within the brklge device: 

ANNOUNCE serverHTTP HTTP/ 
1.1 Location:httpuV/bridge.com:1 23 
[0075] The URL 'server HTTP" is the type of the sen^- 
ice. The location field contains the URL to reach the 
sen/ice. It is composed of the address of the brk^ge de- 
vice ar^ a port number chosen by the bridge device and 
dedicated to the HTTP proxy associated with the HAVi 
target. 

[0070] Each time a new proxy has to be activated, the 
bridge device chooses a new (private) port number re- 
lated to the transport protocol used to reach tt^t senfice 
(either UDP or TCP). 

[0077] The entity body of the ANNOUNCE message 
will contain the following fields which help to identify the 
device hosting the service: 



Device manufacturer name 
Device name 

- A URL to obtain an icon representing the device 

5 [0078] It is possible also that the SSDP server of th 
brkfge device receives an OPTIONS message from any 
UPnP device. The brkige will teve to respond according 
to the description presented earner 
[0079] Consequently the proxy service shall maintain 

10 a set of configuratkxi data to be able to kientify and join 
its associated HAVi target (either a DCM or a FCM). This 
configuration data shall comprise the Software Element 
Identifier (SEID) of the HAVi target 
[0080] Once a proxy is InstaQed and declared to the 

»s UPnP sub-network, any appifcation in the UPnP sub- 
network can then control these HAVI targets. In our ex- 
ample (cf Figure 3) the device D provides to the user the 
list of devices in its home network represented by icons. 
To realize that, the user applicatk>n of device D (a HTML 

20 browser) has previously queried the UPnP sub-networtc 
through the SSDP OPTIONS method to get the descrip- 
tkxi of all devices which implement a HTTP sen/er serv- 
ice. 

[0081] The user wouM like to control the device B us- 

2S ing HTML and selects its assoceted icon. The user ap- 
plication in device D establishes the TCP connection 
with the HTTP proxy -associated with the HAVi target 
device B-embedded in the bridge device. The HTTP 
proxy then establi^es a HTTP connection with the 

30 DCM representing the HAVi target calling the DCM::Ht- 
tpOpen method as described earlier. The User applica- 
tion then sends the HTTP request to the HTTP proxy 
throu^ the TCP connecton. The HTTP proxy then for- 
wards the HTTP request to the HAVi target device B (in 

35 fact its DCM) by calling the f unctbn DCM::HttpRequest. 
The DCM then sends back the HTTP response (its 
HTML homo page for instance) by calling the HTTP 
proxy (method <client>::HttpResponse) acting as the 
HTTP cGent within the HAVi sub<ietwork. The HTTP 

40 proxy then will forward the response to the user appli- 
cation kx3ted in device D. 

[0082] Although the preferred embodiment concerns 
the interoperability of a UPnP sub-network and of a HAVi 
sutMietworic. the invention is not limited to these two 
45 networic types and may also be applied to other types 
of networks. 



Claims 

50 

1 . Method for bridging a HAVi sub-network and a UP- 
nP sub-network comprising the steps of: 

- discovering UPnP devk:es and/or sendees on 
ss the UPnP sub-network and corresponding to a 

selectkxi criterbn; 

- dectaratkxi, by a subnetwork bridging devk:e, 
cH each discovered UPnP devbe as a HAVi 
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OCM and of each discovered UPnP seivice as 
a HAVi FCM on the HAVi GUb-networK. 

2. Method according to claim 1 , wherein the discovery 
step is carried ut using Simple Sennce Disccvery 5 
Protocol (SSDP) functions. 

3. Method lor brfeJging a HAVi sub-network and a UP- 
nP sub-network comprising the steps o^. 

TO 

- discovering HAVi software elements of the 
HAVi sub-network corresponding to a selectton 
criterion; 

- representing, in a sub-network bridging device, 
each of sakj discovered elements by a UPnP ^5 
proxy service identified by a port numt>er attrit>- 
uted by said sub-network bridging device; and 

- announcing each said proxy services on the 
UPnP sub-nelworic 

20 

4. Method according to claim 3, wherein the discovery 
step comprises the step requesting, by said sub- 
network bridging device, a list of software elements 
from a HAVi registry. 

5. Method according to one of the preceding claims, 
wherein the selection criterion is HTTP/HTML ca- 
pability. 

6. Device for bridging a UPnP sub-network and a HAVi ^ 
sub-network implementing the methods according 

to one of the claims 1 to 5. 
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